home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group00a.txt / 000093_icon-group-sender _Fri May 12 10:19:29 2000.msg < prev    next >
Internet Message Format  |  2001-01-03  |  5KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA00987
  4.     for icon-group-addresses; Fri, 12 May 2000 10:18:52 -0700 (MST)
  5. Message-Id: <200005121718.KAA00987@baskerville.CS.Arizona.EDU>
  6. From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
  7. To: "Ray Pereda" <raypereda@hotmail.com>, <icon-group@optima.CS.Arizona.EDU>
  8. Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
  9. Date: Fri, 12 May 2000 01:14:09 -0400
  10. X-Priority: 3
  11. X-MSMail-Priority: Normal
  12. X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
  13. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  14. Status: RO
  15.  
  16. ----- Original Message -----
  17. From: "Ray Pereda" <raypereda@hotmail.com>
  18. To: <ian.trudel@tr.cgocable.ca>; <icon-group@optima.CS.Arizona.EDU>
  19. Sent: Tuesday, May 02, 2000 1:36 AM
  20. Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
  21.  
  22.  
  23. > Hi Ian,
  24. >
  25. > >How about investigate a "pluginizable" data type for Icon?
  26. >
  27. > The Jcon design makes it easy to add new data types.  In the
  28. object-oriented
  29. > implementation every data type is derived from a common base class that
  30. has
  31. > many useful defaults.  Go to the www.cs.arizona.edu/icon to read more
  32. about
  33. > Jcon.
  34. >
  35. > >Data type could be added to the Icon's runtime system on the fly.
  36. >
  37. > I've heard this idea mentioned before.  This would take a little bit more
  38. > thinking things through, but it would be a big win for Icon programmers.
  39.  
  40. Hello,
  41.  
  42.     I agree on this, the extra flexibility given by such system would be
  43. really interesting. It would probably also avoid multiple version, or
  44. distribution, of Icon, such as Unicon, MT Icon, etc. (Speaking of
  45. 'distroing', that's something I dislike from Linux. There is like a gazilion
  46. of distro, making the thing hard sometime..)
  47.  
  48. I've glanced the Jcon source code. Truely remarkable, adding a new data type
  49. is pretty simple. That's not so true for the original Icon system though.
  50. The main problem is the primitive data types are embedded in some
  51. switch()s', so adding a new type requires editing many files and stuff.
  52. That's error prone. However, it would certainly be possible to add a new
  53. dynamic primitive, which would allow us to add new primitives on the fly.
  54. This could also allow either statically linked (with Icon source) or
  55. dynamically linked (shared library or dynamic linked library). This special
  56. primitive could let a third party 'register' his new data type along his
  57. special functions. The primitive system would, of course, expecting some
  58. basic functions such as data convertion or Icon operators, for example. Note
  59. the dynamic primitive data type would requires us to add only one new
  60. descriptor.
  61.  
  62. But Hey, hang on a minute.. why not rewrite the whole primitive system
  63. (*giggles*) now we speaking of it! A certain system dictionary could
  64. maintain the primitive set and manage them. No need of a dynamic dictionary,
  65. I think the primitive data types should be a limited ressource anyway. A
  66. limit of 255 primitives would be just enough for a while! Anyway, we should
  67. be able to register a primitive to the system (or) primitive dictionary,
  68. along the new functions. If name spacing possible, no need to register basic
  69. functions (such as convertion), they could have standard name (such as
  70. toString, toCSet, toInteger, ..., or fromInteger, etc) or if none found, the
  71. prim's function is automatically failing. This would be also good at the
  72. source code level, each primitive could be a new C file. So, if I want to
  73. dig into CSet functionalites, I glance in primCSet.c (or whatever). Things
  74. are clear in the implementation book and the tech reports, but at the source
  75. code level, it's somehow mixed up and there is no roadmap. Erm..
  76.  
  77. There is some bad sides of this, of course, like changing the whole source
  78. is not so trivial or making primitives co-existing may be sometimes hard
  79. (hey, what happen if you add a new prim? do we have to add convertion
  80. functions to each other prims? etc)... what else.. a new C interface (for
  81. loadable C fonction) would be needed? Anyway, I'm pretty sure you can find
  82. others.
  83.  
  84. Icon implementation is not as simple as Smalltalk, for example, but it's
  85. nonetheless interesting. There is lotsa things from Smalltalk (or Squeak)
  86. that could be good in Icon without changing the whole Icon's implementation.
  87. I know the Icon project ppl seeking the stability and portability of their
  88. programming language, but I think the dynamic primitive data type system
  89. would just be awesome!! It'd certainly worth the effort.
  90.  
  91. Any thoughts?
  92.  
  93. Ok, I'm off to bed..
  94. Ian Trudel
  95.  
  96. PS: If you're curious, check out these URL (Squeak primitive stuff):
  97. http://www.create.ucsb.edu/squeak/DIYSqPrims.html
  98. http://minnow.cc.gatech.edu/squeak/464
  99.  
  100.